Method for compressing data in a bit stream or bit pattern

ABSTRACT

One embodiment of the present invention is directed to a method for a computer graphics system comprising compressing a plurality of groups of bits by shifting compressed groups of bits into bit positions that are to be removed during the compression, the logic being responsive to a mask, wherein contents of the mask define variable amounts that the plurality of bits are shifted during the compression. Another embodiment is directed to a method for compressing a plurality of groups of bits to eliminate groups of bits that are to be unaffected by a computation, performing the computation, and thereafter decompressing corresponding data after performing the computation to restore data corresponding to previously eliminated groups of bits.

CROSS-REFERENCE TO RELATED APPLICATION

The present invention claims the benefit of U.S. provisional applicationSer. No. 60/515,841, filed Oct. 29, 2003, and entitled “System AndMethod For Providing Variable Length Compression Between Successive BitPositions In A Bit Stream Or Bit Pattern.” This provisional applicationis hereby incorporated by reference in its entirety.

FIELD OF THE INVENTION

The present invention generally relates to graphics systems, and moreparticularly to an method for compressing data in a bit stream or bitpattern.

BACKGROUND

As is known, the art and science of three-dimensional (“3-D”) computergraphics concerns the generation, or rendering, of two-dimensional(“2-D”) images of 3-D objects for display or presentation onto a displaydevice or monitor, such as a Cathode Ray Tube (CRT) or a Liquid CrystalDisplay (LCD). The object may be a simple geometry primitive such as apoint, a line segment, a triangle, or a polygon. More complex objectscan be rendered onto a display device by representing the objects with aseries of connected planar polygons, such as, for example, byrepresenting the objects as a series of connected planar triangles. Allgeometry primitives may eventually be described in terms of one vertexor a set of vertices, for example, coordinate (x, y, z) that defines apoint, for example, the endpoint of a line segment, or a corner of apolygon.

To generate a data set for display as a 2-D projection representative ofa 3-D primitive onto a computer monitor or other display device, thevertices of the primitive are processed through a series of operations,or processing stages in a graphics-rendering pipeline. A genericpipeline is merely a series of cascading processing units, or stages,wherein the output from a prior stage serves as the input for asubsequent stage. In the context of a graphics processor, these stagesinclude, for example, per-vertex operations, primitive assemblyoperations, pixel operations, texture assembly operations, rasterizationoperations, and fragment operations.

In a typical graphics display system, an image database (e.g., a commandlist) may store a description of the objects in the scene. The objectsare described with a number of small polygons, which cover the surfaceof the object in the same manner that a number of small tiles can covera wall or other surface. Each polygon is described as a list of vertexcoordinates (X, Y, Z in “Model” coordinates) and some specification ofmaterial surface properties (i.e., color, texture, shininess, etc.), aswell as possibly the normal vectors to the surface at each vertex. Forthree-dimensional objects with complex curved surfaces, the polygons ingeneral must be triangles or quadralaterals, and the latter can alwaysbe decomposed into pairs of triangles.

A transformation engine transforms the object coordinates in response tothe angle of viewing selected by a user from user input. In addition,the user may specify the field of view, the size of the image to beproduced, and the back end of the viewing volume so as to include oreliminate background as desired.

Once this viewing area has been selected, clipping logic eliminates thepolygons (i.e., triangles) which are outside the viewing area and“clips” the polygons, which are partly inside and partly outside theviewing area. These clipped polygons will correspond to the portion ofthe polygon inside the viewing area with new edge(s) corresponding tothe edge(s) of the viewing area. The polygon vertices are thentransmitted to the next stage in coordinates corresponding to theviewing screen (in X, Y coordinates) with an associated depth for eachvertex (the Z coordinate). In a typical system, the lighting model isnext applied taking into account the light sources. The polygons withtheir color values are then transmitted to a rasterizer.

For each polygon, the rasterizer determines which pixel positions arecovered by the polygon and attempts to write the associated color valuesand depth (Z value) into frame buffer. The rasterizer compares the depthvalues (Z) for the polygon being processed with the depth value of apixel, which may already be written into the frame buffer. If the depthvalue of the new polygon pixel is smaller, indicating that it is infront of the polygon already written into the frame buffer, then itsvalue will replace the value in the frame buffer because the new polygonwill obscure the polygon previously processed and written into the framebuffer. This process is repeated until all of the polygons have beenrasterized. At that point, a video controller displays the contents of aframe buffer on a display a scan line at a time in raster order.

With this general background provided, reference is now made to FIG. 1,which shows a functional flow diagram of certain components within agraphics pipeline in a computer graphics system. It will be appreciatedthat components within graphics pipelines may vary from system, and mayalso be illustrated in a variety of ways. As is known, a host computer10 (or a graphics API running on a host computer) may generate a commandlist 12, which comprises a series of graphics commands and data forrendering an “environment” on a graphics display. Components within thegraphics pipeline may operate on the data and commands within thecommand list 12 to render a screen in a graphics display.

In this regard, a parser 14 may retrieve data from the command list 12and “parse” through the data to interpret commands and pass datadefining graphics primitives along (or into) the graphics pipeline. Inthis regard, graphics primitives may be defined by location data (e.g.,x, y, z, and w coordinates) as well as lighting and texture information.All of this information, for each primitive, may be retrieved by theparser 14 from the command list 12, and passed to a vertex shader 16. Asis known, the vertex shader 16 may perform various transformations onthe graphics data received from the command list. In this regard, thedata may be transformed from World coordinates into Model Viewcoordinates, into Projection coordinates, and ultimately into Screencoordinates. The functional processing performed by the vertex shader 16is known and need not be described further herein. Thereafter, thegraphics data may be passed onto rasterizer 18, which operates assummarized above.

Thereafter, a z-test 20 is performed on each pixel within the primitivebeing operated upon. As is known, this z-test is performed by comparinga current z-value (i.e., a z-value for a given pixel of the currentprimitive) in comparison with a stored z-value for the correspondingpixel location. The stored z-value provides the depth value for apreviously-rendered primitive for a given pixel location. If the currentz-value indicates a depth that is closer to the viewer's eye than thestored z-value, then the current z-value will replace the stored z-valueand the current graphic information (i.e., color) will replace the colorinformation in the corresponding frame buffer pixel location (asdetermined by the pixel shader 22). If the current z-value is not closerto the current viewpoint than the stored z-value, then neither the framebuffer nor z-buffer contents need to be replaced, as a previouslyrendered pixel will be deemed to be in front of the current pixel.

Again, for pixels within primitives that are rendered and determined tobe closer to the viewpoint than previously-stored pixels, informationrelating to the primitive is passed on to the pixel shader 22 whichdetermines color information for each of the pixels within the primitivethat are determined to be closer to the current viewpoint. Once colorinformation is computed by the pixel shader 22, the information isstored within the frame buffer 24.

Although the foregoing has only briefly summarized the operation of thevarious processing components, persons skilled in the art recognize thatthe processing on graphics data is quite intense. Consequently, it isdesired to improve processing efficiency wherever possible.

SUMMARY OF THE INVENTION

Certain objects, advantages and novel features of the invention will beset forth in part in the description that follows and in part willbecome apparent to those skilled in the art upon examination of thefollowing or may be learned with the practice of the invention. Theobjects and advantages of the invention may be realized and obtained bymeans of the instrumentalities and combinations particularly pointed outin the appended claims.

One embodiment of the present invention is directed to a method for acomputer graphics system comprising compressing a plurality of groups ofbits by shifting compressed groups of bits into bit positions that areto be removed during the compression, the logic being responsive to amask, wherein contents of the mask define variable amounts that theplurality of bits are shifted during the compression.

Another embodiment is directed to a method for compressing a pluralityof groups of bits to eliminate groups of bits that are to be unaffectedby a computation, performing the computation, and thereafterdecompressing corresponding data after performing the computation torestore data corresponding to previously eliminated groups of bits.

Other embodiments and variations of the invention will be discribed inthe detailed description that follows.

DESCRIPTION OF THE DRAWINGS

The accompanying drawings incorporated in and forming a part of thespecification illustrate several aspects of the present invention, andtogether with the description serve to explain the principles of theinvention. In the drawings:

FIG. 1 is a block diagram of a conventional graphics pipeline, as isknown in the prior art.

FIG. 2 is a block diagram illustrating certain elements of a graphicscomponent constructed in accordance with one embodiment of theinvention.

FIG. 3 is a block diagram illustrating elements of an embodiment of theinvention, as embodied in components within a graphics pipeline.

FIG. 4 is a block diagram illustrating a graphics pipeline havingelements that are constructed in accordance with an embodiment of theinvention.

FIG. 5 is a block diagram illustrating portions of a graphic systemconstructed in accordance with another embodiment of the presentinvention. See changes on FIG. 5.

FIGS. 6A-6F illustrate steps of one embodiment for generating a maskthat may be used in embodiments in the present invention.

FIG. 7 is a block diagram illustrating components of a graphic systemfor compressing data, in accordance with an embodiment of the presentinvention.

FIG. 8 is a block diagram illustrating components of a system forcompressing data in accordance with another embodiment of the presentinvention.

FIG. 9 is a diagram illustrating one embodiment of a logic component forcompressing signals, bits, or positions within a data stream, inaccordance with an embodiment of the present invention.

FIG. 10 is a block diagram illustrating a mechanism for generatingselect signal lines for the multiplexers shown in FIG. 9, in accordancewith an embodiment of the present invention.

FIG. 11 is a block diagram illustrating the creation of a data streamhaving compressed data, in accordance with one embodiment of the presentinvention.

FIGS. 12A and 12B are diagrams similar to FIGS. 10 and 9, respectively,illustrating the operation of the logic elements of those figures with ahypothetical example.

FIG. 13 is a block diagram illustrating certain components of anembodiment of the present invention, which operate to compress anddecompress data.

FIG. 14 is a block diagram similar to FIG. 9, but illustrating logic forperforming a decompression operation, in accordance with an embodimentof the invention.

DETAILED DESCRIPTION

Having summarized various aspects of the present invention, referencewill now be made in detail to the description of the invention asillustrated in the drawings. While the invention will be described inconnection with these drawings, there is no intent to limit it to theembodiment or embodiments disclosed therein. On the contrary, the intentis to cover all alternatives, modifications and equivalents includedwithin the spirit and scope of the invention as defined by the appendedclaims.

It is noted that the drawings presented herein have been provided toillustrate certain features and aspects of embodiments of the invention.It will be appreciated from the description provided herein that avariety of alternative embodiments and implementations may be realized,consistent with the scope and spirit of the present invention.

As summarized above, the present application is directed to embodimentsof systems for providing variable length compression between successivebit positions (or groups of bits) in a bit stream or a bit pattern. Oneembodiment of the invention includes logic elements referred to aspackers and unpackers, incorporated in hardware for computer graphicsystems. It should be appreciated that the invention, however, is notlimited to this embodiment or environment. Implementations ofembodiments of the invention include one or more logic elements forcompressing data (sometimes referred to as a packer) and one or morelogic elements for decompressing previously compressed data (sometimesreferred to as unpacker).

As will be described further herein, there are several locations in agraphics system where features or aspects of the invention may beimplemented. Likewise, it will be appreciated from the descriptionherein that there are systems and environments in fields other thancomputer graphics where the concepts of the invention may be employed aswell.

The bit compression, or pixel-packing, feature of one embodiment may beimplemented prior to performing a pixel-shading operation. As the nameimplies, and as is known, pixel shading operations are performed on aper-pixel basis. However, for a variety of reasons, many pixels of agiven primitive may not require the pixel shading operation. Forexample, pixels of a primitive that are covered by other primitives(e.g., as determined by a Z test) need not have the pixel shadingoperation performed on them. Such pixels may be identified and removedfrom the bit sequence, before being sent to the pixel shader. In thisregard, a bit sequence may be compressed such that only pixels to beoperated upon are sent to the pixel shader.

Reference is made briefly to FIG. 2, which illustrates certain basiccomponents of an embodiment of the invention. FIG. 2 includes acomponent labeled “graphics component” 110, which may designate orrepresent hardware components in a graphics pipeline. Within thiscomponent, logic 112 may be provided for providing variable-lengthcompression of a bit sequence (e.g., bit packing). Likewise, companionlogic 114 may be provided for decompression (or unpacking) the bitsequence after processing. This embodiment of the invention may beimplemented in systems that provide programmable processing for certainfunctions, referred as GPU (Graphic Processing Units), such as the pixelshading, rather than using dedicated hardware for performing thisfunction. In such a system, the elimination of pixels that do not needto be processed, through the pixel packing process described herein,greatly improves the efficiency of the programmable GPU processor.

Reference is made briefly to FIG. 3, which illustrates (generically)certain components of a graphics pipeline, which may implement featuresof embodiments of the invention. As illustrated, a host computerprovides input to a graphics pipeline in the form of primitive andgeometry data. This information and communication is well known, andneed not be described herein. As is further known, the graphics pipelineincludes a series of functional and/or logical components that performprocessing tasks on the graphics information that is communicated fromthe host computer. These components are illustrated in FIG. 3 ascomponent 1 120, component 2 130, . . . component N 140. Thesecomponents may take on a variety of different forms, which may varywidely from implementation to implementation, as graphics hardware isknown to have widely differing implementations. Generalizing, however,the front end of the processor (component 1 120) typically receivesprimitive geometry information and performs certain geometry orvertex-based operations. These type of operations includetransformations, lighting, triangle set-up, etc.. In some embodiments,the front end of the graphics pipeline may also include logic forperforming a tessellation operation, which breaks up primitives intosmaller primitives or triangles. After the graphics pipeline front-endoperations, further processing such as span and tile generation(triangle rasterization), Z-test, pixel shading, alpha test/alpha blend,etc. may be performed. These operations are well known by personsskilled in the art, and therefore need not be described herein.

An embodiment of the present invention includes logic 132 for packingthat performs a packing operation on a bit sequence in internalcomponents of the graphics pipeline. In one embodiment, the packingoperation is usefully employed on pixel, rather than vertex, operations.Furthermore, the logic for packing may be implemented in more than oneinternal component. For example, in one embodiment, the packing logic132 may be provided before performing a pixel shading operation.Likewise, the packing function may also be employed in a Z compressor(which generates compressed Z information).

Logic for unpacking 142 may also be provided downstream of the packinglogic 132. The unpacking operation is the substantial inverse of thepacking operation, and is preferably implemented using a similar,companion logic structure and method as the packing operation. Indeed,the same mask used in the packing operation is used in the unpackingoperation. Therefore, a description of the structure and operation oflogic that performs the packing operation is sufficient to enable oneskilled in the art to likewise implement an unpacking operation.

FIG. 4 illustrates certain of these components in one embodiment of agraphics pipeline implementing packing and unpacking functions.

More specifically, FIG. 4 illustrates an embodiment of the presentinvention in which a graphics pipeline, employing many conventionalcomponents, embodies certain inventive features. For example, thecommand parser 162, vertex and geometry shader 164, triangle setup 166,and the span/tile generation 168 are well-known operations, and need notbe described herein. Also known is a z-range test 170, in which a z-testis performed on compressed z-data. Compressed z-tests performed in thisway may improve efficiency by trivially accepting or trivially rejectingcertain primitives (or alternatively ranges of pixels) based uponcompressed z-information. A similar, per-pixel, test may be performed bythe pixel z-test block 180.

A z-cache 172 may be coupled to both blocks and provide a high speedmemory access for z-data (e.g., higher speed retrieval and access thanfrom the z-buffer memory). A z-compressor 174 may also be provided. Asis known, z (or depth) data may be compressed for evaluation andefficiency enhancements. In one embodiment of the invention, however,the mechanism for compressing z-information may embody elements forpacking 176 and unpacking 178 z-data. In this regard, and as will bedescribed in more detail below, a pixel mask (generated using depthinformation) may be utilized to define variable shift lengths, whichcause bits or data in a data stream to be shifted so as to overwritedata preceding the data being shifted. Prior to performing thiscompression/shift operation, a determination may be made as to pixeldata that is not to be affected by a computation (such as the z-rangetest).

As is known, there are various ways to compress z-data. Onestraightforward approach is, for a given tile (a 4×4 pixel tile, 8×8tile, or other size tile) to save only the minimum and maximum z-valuesfor that tile. In such a situation, a 16-pixel tile would be compressedfrom sixteen down to two z-values (the minimum and the maximum). Thez-compressor 174 may generate a pixel mask of this 4×4 tile byallocating a single bit to each tile position and recording a one in thebit for a given tile position if that pixel is either a minimum ormaximum z-value for that tile. Zeros would be recorded in all remainingbit positions. The logic for packing 176 may then left-shift the pixelinformation associated with the pixel positions having mask values ofone, while removing all other pixel information. Only this compressedinformation, in one embodiment, is sent to the block 170 for performingthe z-range test. Eliminating data that would not be impacted by thecalculation of the z-range test reduces the computations performed bythat logic block, and therefore improves its calculation efficiency.

The graphics pipeline of FIG. 4 also illustrates logic for performing apixel packing operation 182, a pixel shader 184, a block for performingan alpha test 186, and logic for performing a pixel unpacking operation188. The pixel shader 184 and alpha test 186 blocks perform functionsthat are known in the art, and need not be described herein. As the nameimplies, the pixel shader 184 performs shading operations on a per-pixelbasis. For a given graphic primitive that is being operated upon, or fora given tile in tile-based operations, often a number of the pixels willultimately not be visible to a user (based on depth information,obstruction by other objects between the current pixel and the viewpoint, etc.). For all such pixels, the pixel shading and alpha testoperations need not be performed. Therefore, it may be desired tocompress the pixel information so that only information or data to beimpacted by the computations performed by the pixel shader and/or alphatest operations are passed through the pipeline to those logic blocks.

The logic for pixel packing 182 may perform a compression on the pixeldata passed to it from above in the graphics pipeline. The logic forpixel packing 182 may operate similar to the logic for packing 176,which was summarized above in connection with the z-compressor 174. Aswill be described in more detail below, a mask (such as a pixel mask)may be formed, based upon depth information, and used to controlcompression of the data. Specifically, data that is to be used orimpacted in performing pixel shader and alpha test operations iscompressed, while data not to be affected by those operations orcomputations is removed from the bit stream before it is passed throughthe pipeline to the pixel shader 184 and alpha test 186 logic blocks.Ultimately, this removed data is restored by the logic for pixelunpacking 188.

Referring briefly to FIG. 5, a portion of the components illustrated inFIG. 4 is illustrated. Further, in FIG. 5, the embodiment is illustratedin a graphics pipeline having a shared multi-threaded parallel processorthat is available for performing centralized processing operations forseveral of the logic components within the graphics pipeline. In thisembodiment, rather than each component or logic block in the graphicspipeline being performed by dedicated hardware, certain processingfunctions may be communicated to a centralized and shared programmableprocessing resource 210 for execution. In one embodiment, the processingunit may be implemented as a multi-threaded processor 210. Such aprocessor may include scheduling logic for managing tasks that arecommunicated to it for processing. As is described further herein, thelogic packing 282 may be controlled by a suitable mask 224 (such as apixel mask), which may identify the bit (pixel) locations or positionsthat should be preserved, as well as those that may be discarded in thecompression or packing operation. This mask 224 may be stored in astorage region 220 that is centrally accessible, as it may be used bythe logic for unpacking, so that the original bit sequence may berestored.

From an operational or functional standpoint, the elements illustratedin FIG. 5 perform similar to the corresponding elements of FIG. 4.However, since the graphic system of FIG. 5 includes a sharedmulti-threader processor 210, some of the operations that are performedin the individual logic blocks may be centrally performed by theprocessor 210. In such an embodiment, the internal structure of thevarious logic blocks may differ slightly, even though the functionalaspect is the same (as that of FIG. 4).

As described in FIG. 4, pixel masks may be used by the packers andunpackers (i.e., compressors and decompressors) for the data. FIG. 5illustrates two such masks 222 and 224, which may be stored, along withother data, in a tile-based storage area 220. Of course, the contents ofa pixel mask 222, for a given tile, for the z-compressor may bedifferent than the content of the pixel mask 224 of the correspondingtile for the pixel packer. Therefore, these masks have been separatelyillustrated in FIG. 5.

It should be appreciated that, in systems such as that illustrated inFIG. 5, the benefits of the compression performed in embodiments of theinvention are significant. That is, in an embodiment utilizing sharedresources of a multi-threaded processor 210, overall system efficiencyis significantly enhanced if the efficiency of the multi-threadedprocessor is enhanced. Without implementing the compression of anembodiment of the invention, the pixel shader 284 may otherwise senddata for all pixels to be processed by the processor 210. For pixelsthat are not to be visible on the display, any processing performed onsuch pixels in the pixel shading operation is effectively wastedprocessing. The utilization of a shared resource, such as the processor210, in performing this operation, prevents the processor fromprocessing other requests or performing tasks for other elements withinthe pipeline. Therefore, the compression performed by the logic forpixel packing 282 provides significant performance improvements of theprocessor 210, as it operates in the system as a whole.

Reference is now made to FIG. 6, which illustrates the generation of amask of a type that may be utilized in embodiments of the presentinvention, described hereinafter. It should be appreciated that theillustration of FIGS. 6A-6F are significantly simplified to facilitatethe illustration of certain aspects of embodiments of the invention.However, the simplified illustration provided herein is sufficient forpersons skilled in the art to implement more complex and realisticexamples.

Referring first to FIG. 6A, a triangle primitive 320 is shown within theboundaries of a display 310. As is well known, a computer graphicsdisplay will typically render thousands, and often hundreds ofthousands, of primitives in a single graphics display. Primitives arefrequently broken down to triangle primitives, such as triangle 320. Asis known, early (front end) components in a graphics pipeline performcertain setup and vertex-based operations on the primitives. Span andtiled generation components will break a primitive up into scan lines322 (FIG. 6B) and tiles defined by vertical lines 324 crossing the spanlines 322 (FIG. 6C). Squares on the tile are often grouped into tiles of2×2, 4×4, 8×8, or other sized dimensions. FIG. 6D illustrates a tile 326having a dimension of 4×4 pixels. The alignment of tile 326 isarbitrarily illustrated with reference to the triangle primitive 320.The portions of the triangle primitive 320 that fall outside the 4×4tile are discarded, and FIG. 6E illustrates the tile 326 and theoverlapping portion of the triangle primitive 320, shown in crosshatch328. Each pixel may there after be represented by a one or a zero(single bit) to indicate whether the primitive 320 occupies apredominate portion of a given pixel or not. In this regard, it isobserved (from FIG. 6D) that five of the pixels of the tile 326 arecompletely covered by the primitive. 320. These are the four pixels ofthe bottom right hand corner of tile 326 and the pixel above the four.Likewise, the four pixels along the left vertical edge of tile 326 arenot covered at all by the primitive 320. The remaining pixels have someportion that are covered by the primitive 320. Mechanisms to minimizealiasing or provide blending of primitives whose boundaries fall acrosspixels are well known and need not be described herein. From arelatively straightforward standpoint, a pixel mask 330 (see FIG. 6F)may be created by placing a one (single bit) in the pixel locations inwhich a majority of the pixel is covered by the primitive 320. Theresult may be a pixel mask having content such as that illustrated inFIG. 6F.

While the foregoing presents one method for generating a pixel mask,more complex methods may be (and will likely be) implemented as well.For example, depth information of other primitives that may fully orpartially overly a current primitive may be taken into consideration aswell. It will be appreciated, however, the present invention is notlimited to any particular method or methods for generating a pixel mask,but that a variety of methods, consistent with the scope and spirit ofthe present invention may be implemented. In this regard, embodiments ofthe invention that call for the generation of a pixel mask (or othermask) contemplate a wide variety of methods for generating such masks.

Having set forth the foregoing, reference is now made to FIG. 7, whichis a block diagram illustrating one embodiment of the present invention.Specifically, FIG. 7 illustrates a portion 350 of a graphic system forcompressing pixel data for subsequent operations by elements within agraphics pipeline or graphic system. As previously illustrated, graphicsinformation is passed into a graphics pipeline from a host. Certainsetup and vertex operations may be performed, but graphics data isultimately stored in a memory. After span and tile operations have beenperformed, such a memory may hold graphics data or content for aplurality of tiles of pixels. FIG. 7 illustrates a memory 352 havingpixel data or content for a given tile n. Of course, the memory 352 mayinclude data for other tiles as well. Logic 354 is provided forcompressing the content of the graphics data for subsequent operationsor computations by other components in the graphic system. Thecompression logic utilizes a mask for performing the compression. Inthis regard, the mask identifies pixel locations having data that is notto be affected by a subsequent operation or computation, and thereforemay be removed during the compression operation. In the preferredembodiment, the mask is a pixel mask.

As further illustrated in FIG. 7, a pixel mask 356 is provided for tilen, which is to be compressed. In one embodiment, the logic forcompressing 354 generates an output 358 containing the compressed pixeldata or content for tile n. In an alternative embodiment, the output ofthe logic for compressing 354 may simply be an identification of memorylocations within the memory 352 of the data that is to be operated upon(effectively decompressed data). The processor or other operationalelement within the graphic system that is to perform an operation uponthe compressed data may retrieve the data from the memory 352, ifappropriate.

In one embodiment, the elements of FIG. 7 may be replicated to performcompression of multiple tiles of pixel data. In another embodiment, theelements illustrated in FIG. 7 may be scalable so as to store and managethe compression of multiple tiles of pixel data.

Reference is now made to FIG. 8, which is a block diagram of analternative embodiment of the present invention. In this embodiment, amask (such as a pixel mask) is used by a controller 362 to control theoperation of a packer 364. The packer 364 performs a variable-lengthcompression operation on unpacked pixel data 366 that is provided toinput the packer (or otherwise associated with the signals provided tothe input). The output of the packer 368 comprises compressed or packedpixel data (or signals associate with the compressed or packed data).Consistent with the scope and spirit of the present invention, there area variety of methods and architectures that may be implemented withinthe components of FIG. 8. FIGS. 9-11 below illustrate one exemplaryembodiment. However, it should be understood, except as expresslyrecited in the appended claims, the present invention should not beconstrued as limited to the embodiment illustrated in the followingfigures.

Reference is now made to FIG. 9, which is a diagram that illustrates onepotential implementation for logic that performs a compression of datain accordance with an embodiment of the invention. The logic 400 of FIG.9 may be used to implement the packer 364 of the embodiment of FIG. 8,as well as that logic for compressing 354 of the embodiment of FIG. 7.With regard to this particular implementation, FIGS. 9, 10, and 11 maybe viewed collectively to gain a more complete understanding of themanner in which a mask may be used to variably compress data (or groupsof bits) in accordance with one embodiment.

Beginning with FIG. 9, data to be compressed may be provided in a latch,such as a tile data latch 410. In the illustrated embodiment, there are16 bit positions (bit 0 through bit 15) of the data that is to becompressed. A signal output of each of these bit positions is connectedto an input of a multiplexer that is arranged in a first row ofmultiplexers. In one embodiment, each bit position of the tile latch 410corresponds to (or is associated with) a bit position within the mask(e.g., FIG. 6F) that is used to define the compression for the dataassociated with the tile data latch 410. It should be appreciated thatthere are various ways that data may be compressed using the structureof the logic of FIG. 9. For example, if each position defined within amask (e.g., FIG. 6F) corresponds to one or more bytes of data (which inmost embodiments it will), then the structure of FIG. 9 may bereplicated for each bit of information corresponding to a given a tileposition. By way of example, if each position of the mask corresponds toa byte (8 bits) of data, then the structure of FIG. 9 may be effectivelycascaded eight layers deep. The bit 0 position of the tile data latch410 of the first layer may hold the least significant bit of the byte ofdata within the data range to be compressed. Likewise, the bit 0position of the tile data latch 410 of the second layer of the logic ofFIG. 9 (successive layers not illustrated) may hold the next leastsignificant bit of the data corresponding to that mask location.Replicating the structure illustrated in FIG. 9 in this way allowsgroups of bits to be compressed. As will be described below, all bits ina group (e.g., all bits associated with a given bit position of the tiledata latch) are either retained or discarded in a compression operation.That is, if the bit of bit 0 position of the first layer is notdiscarded through compression, then none of the bits of the bit 0position (of any layer) will be discarded through compression. Likewise,if the bit of bit 0 position of the first layer is discarded throughcompression, then all of the bits of the bit 0 position (of any layer)will be discarded through compression.

The structure of FIG. 9 may also be utilized in alternative ways toachieve data compression. For example, in embodiments where largeamounts of data are associated with each bit position of the tile datalatch, replicating the structure of FIG. 9 to accommodate every bitposition of the data may result in an undesirably large amount ofhardware. In such an embodiment, the data that is stored in the tiledata latch may be address data (or a pointer) that points to the startof a data record in memory (again multiple layers of the logic structureof FIG. 9 may be used). A priori information about the data stored atthose memory locations would allow such an embodiment to be used. Thiswould reduce the logic required as a smaller group of bits may beutilized to define the address of data, that actually required forhandling the data itself.

For example, in a computer graphics system, there may be a significantamount of graphics data associated with each pixel position. Thisgraphics data may include color information, such as red, green, blueand alpha (R,G,B,A), depth information (Z), texture information (U and Vcoordinates), etc. If a given pixel is not to be displayed, then all ofthe corresponding information associated with that pixel may becompressed to removed if from certain calculations within the graphicspipeline.

The operation of the structure of FIG. 9 will now be described in thecontext of compressing single bits of data. Again, however, it should berecognized that the logic of FIG. 9 may be readily replicated (orscaled) through additional layers to compress groups of bits of data.

The logic of FIG. 9 provides one structure for variably compressing bitsof data (or groups of bits of data) based upon a mask, by shifting datathat is to be compressed into bit positions of data that are to beremoved. The structure of FIG. 9 allows for very robust operation inthis regard, and the structure of FIG. 10 (described below) provides thecontrol of the various select lines of the multiplexers used in FIG. 9.First describing the structure of FIG. 9, the structure is realizedusing a plurality of rows of multiplexers 402, 404, 406, and 408. Themultiplexers of the a first row of multiplexers 402 have inputs that areconnected to signal lines output from the various bit positions of thetile data latch 410. Each successive row of multiplexers 404, 406, and408 similarly have inputs that are connected to outputs of multiplexersfrom the preceding row. Through controlled selection of the variousmultiplexer inputs, the signal value of a given bit position of the tiledata latch 410 may either be passed straight through to a correspondingbit position of the packet alignment data shifter 420, or alternativelyshifted any number of bit positions to the left. As an example, supposethe data value of bit position 11 of tile data latch 410 is desired tobe shifted to bit position 3 of the packet alignment data shifter 420.This is accomplished by controlling the select inputs for multiplexers432, 434, 436, and 438. Specifically, the control input of multiplexer432 is controlled to select (at its output) the signal value held in bitposition 11. Multiplexer 434 is controlled to select (as its input) theoutput of multiplexer 432. Likewise, multiplexer 436 is controlled toselect (as its input) the output of multiplexer of 434. Finally,multiplexer 438 is controlled to select the output of multiplexer 436.

As can be verified by a ready inspection of the drawing of FIG. 9, eachmultiplexer has two inputs and a single output. As viewed in thedrawing, the 0 input is on the left-hand side of each multiplexer, andthe 1 input is on the right-hand side of each multiplexer. Eachmultiplexer in the first row 402 of multiplexers has as its “0” inputthe corresponding bit position of the tile data latch 410. Eachmultiplexer of the first row has as its “1” input, the bit position ofthe tile data latch 410 one bit to the right of the corresponding bitposition. For ease of nomenclature, the multiplexers of FIG. 9 can beviewed as a matrix, wherein the multiplexers can be designated by thenomenclature R,C, where R designates the row number, and C designatesthe column number. Therefore, the multiplexers of the first row 402 maybe designated as multiplexers 0,0 (e.g., u0,0) through 0,14. Likewise,the multiplexers of the second row 404 may be designated as multiplexers1,0 through 1,13. The multiplexers of the third row 406 of multiplexersmay be designated by numbers 2,0 through 2,11. Finally, the multiplexersof the last row 408 may be designated by numbers 3,0 through 3,7. Due tothe density of the elements shown in FIG. 9, only a sampling of themultiplexers have been designated in this way.

As illustrated, each successive row of multiplexers has fewer than thepreceding row. Further, each multiplexer of the first row has its inputsconnected to two adjacent bit positions of the input data. Eachmultiplexer of the second row has its two inputs connected to the outputof every other multiplexer of the first row. Likewise, every multiplexerof the third row 406 has its two inputs connected to outputs of everyfourth multiplexer in the second row. Finally, each multiplexer of thefourth row 408 has its two inputs connected to every eighth multiplexerof the third row 406. With the multiplexers being connected in thisfashion, the select signal lines in the multiplexers of the fourth rowcontrol a shift of either zero or eight bits (with reference to originalbit positions in the tile data latch 410), depending upon the inputselected. Likewise, the multiplexers of the third row 406 control ashift of either zero or four bits, depending upon the input selected.Similarly, the multiplexers of the second row 404 control a shift ofeither zero or two bits, depending upon the input selected, and themultiplexers of the first row 402 control a shift of either zero or onebit, depending upon the input selected.

The previous example illustrated how multiplexers 432, 434, 436, and 438may be controlled to shift bit 11 of the tile data latch 410 into thebit 3 position of the packet alignment data shifter 420. This compriseda shift of eight bits. If the same data bit (bit position 11 of the tiledata latch 410) were desired to be shifted seven positions (into thefourth bit position of the packet alignment data shifter 420), suchcould be accomplished by select control of the select lines of themultiplexer 442, 444, 446, and 448. In this regard, multiplexer 442 maybe controlled to select the input connected to the eleventh bit positionof the tile data latch 410. Similarly, multiplexer 444 may select theoutput of multiplexer 442, while multiplexer 446 selects the output ofmultiplexer 444, and multiplexer 448 selects the output of multiplexer446.

It should be appreciated that the structure of the logic of FIG. 9 isreadily scalable for masks of various sizes (e.g., data tile latcheshaving differing numbers of bit positions). For example, if the maskwere sized as a 2×2 instead of a 4×4 mask, only three rows ofmultiplexers would be required. These would effectively take the form ofthe three rows of multiplexers shown on the right half of FIG. 9.Similarly, if the logic of FIG. 9 were expanded to accommodate an 8×8mask, then an additional row of multiplexers would be required. In thisregard, the structure of FIG. 9 is readily scalable by a power of two toaccommodate different mask sizes.

It should be appreciated that a key operational aspect of the logicillustrated in FIG. 9 relates to the generation of control signals forcontrolling the proper selection of the various multiplexers. One way ofgenerating these control signals is illustrated in the diagram of FIG.10. As previously described herein, certain embodiments of the inventionimplement masks in the form of pixel masks or tiles. Differing masks maybe used on different tiles of pixels, and indeed for differentprimitives. The embodiment of FIG. 10 illustrates the generation ofcontrol signals for the multiplexers of FIG. 9, in an embodiment using a4×4 mask 452. The bit positions within each tile are assigned a sequenceorder. In this regard, the arrangement or assignments of a particularsequence order is arbitrary, but should be fixed and known for thevarious tiles. For all examples of embodiments described in thisapplication, the sequence order or arrangement in 4×4 masks are asillustrated in the mask 453. That is, the top left position is the zeroposition, with the position immediately to the right being the oneposition, the position immediately below the one position being the twoposition, and so on as specifically illustrated in FIG. 10. Logic 460 isprovided to determine or define the per-pixel shift amount. In thisregard, the logic 460 generates the control signals for the multiplexersof FIG. 9. In one embodiment, the various control values for controllingthe individual multiplexers may be generated by a ROM that is hard codedwith the bit values of the tile mask providing the addressing inputs tothe ROM. The multiplexing and control structure shown in FIG. 9 canreadily be verified as providing any appropriate level of shift to anypixel-pixel slot. Further, by ignoring or overriding all zero values inthe pixel mask, a compression of the bit sequence is achieved.

Returning briefly to FIG. 9, in addition to being arranged in rows, thevarious multiplexers are also arranged in columns, denoted as C0 throughC14. The logic 460 of FIG. 10 generates groups of outputs, which are theselect (control) lines for the multiplexers of various columns. Asillustrated in FIG. 10, there are four signal lines for each of columnsC0 through C7, there are three signal lines for each of columns C8through C11, two signal lines for each of columns C12 and C13, and onesignal line for the multiplexer of column C1 4 (since there is only onemultiplexer in that column).

The logic or circuitry within the multiplexer control logic 460 may beimplemented in a variety of ways. From a functional standpoint, thevalue produced on the signal lines for a given column of multiplexercontrol signals (e.g., C3) results from a computation of the sum of allpreceding bit positions of the pixel mask 453. As previously described,each position of the pixel mask 453 is a single bit (either a 0 or a 1).A zero value in the mask indicates that the data corresponding to thatposition is not to be impacted by a subsequent computation (or isotherwise to be removed in the compression operation). In contrast, alogic one in a particular position of the pixel mask indicates that thecorresponding data is to be impacted by a subsequent computation (or isnot to be removed from the data compression operation). Therefore, whencomputing the summation for a given group of signal lines for a columnof multiplexers (e.g., C3), the summation of bit positions of thepreceding columns (bit positions 0, 1, and 2) are computed. In keepingwith this illustration, there are four multiplexers in column 3, and themultiplexer control logic 460 generates a four bit output (C3) forcontrolling those multiplexers, based on the summation of bit positions0, 1, and 2. Of this four-bit output, the most significant bit controlsthe multiplexer of row 408, while the least significant bit controls theselect lines of the multiplexer in row 402.

Reference is made briefly to FIGS. 12A and 12B, which correspond toFIGS. 10 and 9 (respectively), providing an example of the operation ofthis embodiment for a given pixel mask. As illustrated, there are sixdifferent positions within the pixel mask in which the correspondingdata is to be preserved in the compression operation. This correspondsto the data of mask positions 1, 4, 10, 12, 13, and 14. The variousmultiplexer select values are shown at the outputs of the logic 460 forthis example, and a number (either 0 or 1) is denoted next to eachmultiplexer select line, to show the value that would be applied to eachrespective select line. Likewise, the input data (at the tile data latch410) is generically denoted as D0 through D15. As illustrated at theoutput of the packet alignment data shifter 420, data values D1, D4,D10, D12, D13, and D14 have been shifted into the six left mostpositions of the data shifter 420. To facilitate this illustration, inFIG. 12B, data paths that are unused for the transport of data in thisparticular example are illustrated in dash lines. Likewise, multiplexersthat are not utilized for transporting data are illustrated in dashline, and their control/select input is denoted with an X (don't carevalue).

Returning now to FIG. 10, also illustrated is mask pointer generationlogic 470 and its output 472. In the context of a graphics system, thedata corresponding to numerous tiles for a single display screen will becompressed. The compression amount will vary from tile to tile(depending upon the masks of the individual tiles), and as will bedescribed in more detail in connection with FIG. 11, a system maydenote, or otherwise mark, tile boundaries within a data stream. In theresulting data stream, data values (or groups of bits) corresponding tothe compressed data (as defined by the mask) will be present in the datastream. In the example presented above (FIGS. 12A and 12B), theparticular tile mask had six legitimate data values to be preserved inthe final data stream. Therefore, a mask pointer is generated to markthe boundary of the data corresponding to that tile. In one embodiment,the mask pointer generation logic 470 may simply be a summation of theindividual values of the tile mask 452. This value is also illustratedin the example of FIG. 12A.

Reference is now made to FIG. 11, which is to be viewed in conjunctionwith FIGS. 9 and 10. In this regard, a compressed data stream forprocessing, in a graphic system, will not end with the processing ofdata for a single tile, but will occur many times for many tiles thatcomprise a graphic display. FIG. 11 illustrates four such successivetiles, each having differing mask values. The discussion of FIGS. 9 and10, along with the example presented in conjunction with FIGS. 12A and12B describe how a given tile mask (or pixel mask) can be used togenerate a compressed data value corresponding to that tile. Successivetile masks are used to generate a compressed data stream, comprisingdata corresponding to the plurality of tiles. FIG. 11 illustrates how atile mask 482 is converted into a linear mask 483 (such as the pixelmask 453 of FIG. 10). Since the mask 482 of tile i defines sixlegitimate data positions (or pixel positions having legitimatecorresponding data values), the mask pointer generation logic 470 maygenerate a pointer having a value of six. As shown in the data stream490, the portion of the data stream corresponding to tile i may havedata values D0, D1, D4, D5, D7, and D8, and may then have the insertionof a pointer 492 to denote the end of tile i. Likewise, based upon thevalues presented in tile i+1 484, data values D2, D3, D8, D9, D10, D11,and D13 may be compressed into the data stream 490 followed by a pointer493. Since there are seven bit positions within the mask 484 that are tobe preserved (or retained through the compression), there are sevencorresponding data values provided in the data stream 490. The pointerfor this mask may have a value of seven, which would be added to theprevious pointer value of six creating a value of thirteen. The data andpointer generation value for subsequent tiles may be generated in asimilar fashion.

In addition, in one embodiment of the present invention, the data streamis passed from component to component in a graphic system throughdiscrete-sized data packets. In one embodiment, a data packet maycomprise sixteen data values. If a packet boundary falls in the middleof a tile, then a partial pointer may be inserted, as illustrated inFIG. 11. In this regard, and continuing with:the description, tile i+2486 denotes six mask positions that are to be preserved through thecompression process. These correspond to data values D2, D5, D7, D8,D12, and D13. As illustrated in the data stream of 490, the datacorresponding to this tile is split between packet J and packet J+1.Accordingly, a partial pointer value 495 is inserted at the end ofpacket J with a complete tile pointer 496 being inserted after the thirddata value of packet J+1.

FIG. 11 has been provided merely to illustrate one method or approachfor implementing the management of data values for successive ormultiple tile masks. It should be appreciated that a variety of ways inwhich this aspect may be implemented, consistent with the scope andspirit of the present invention. In this regard, there are various waysand mechanisms for implementing the functionality of the pointers (e.g.,mechanisms for demarcating tile boundaries in the compressed datastream).

Having described certain details regarding one embodiment forimplementing certain features, reference is now made to FIG. 13, whichis a block diagram illustrating features of another embodiment of thepresent invention. In this embodiment, a memory 510 provides storage fordata that corresponds to various positions within a mask. In the contextof a graphic system, each position of a pixel mask may havecorresponding data that includes color information, such as RGB&A, aswell as depth information, texture information (U and V), and a varietyof other attributes that may be associated with pixels in a graphicsystem. The effect and management of this type of information is wellknown by persons skilled in the art, and need not be separatelydescribed herein. In this regard, it is sufficient to note that for eachgiven pixel location, there may be a relatively large quantity of dataassociated with that pixel. The memory 510 of FIG. 13 illustratessixteen discrete areas of memory, wherein each area contains multiplebytes of data, which relate to various attributes of an associatedpixel. Each position of the mask 520 corresponds to an area of thememory 510 containing data.

In accordance with one embodiment of the invention, compression logic525 utilizes contents of the mask 520 to compress data stored within thememory 510. As illustrated in FIG. 13, the mask 520 contains twopositions indicating valid data for that tile. The corresponding memoryareas of memory 510 have also been emphasized. Therefore, aftercompression by the compression logic 525, a reduced amount of data isgenerated as illustrated by 530. This compressed data is then providedto a processor 540 that is configured to perform one or morecomputations on the data 530. In this regard, computation logic 545 isillustrated as being a part of the processor 540. This computation logic545 has been denoted generically as such, as it may encompass a widevariety of different computations, consistent with the scope and spiritof the invention. After the computation is performed, decompressionlogic 550 is provided to restore the data to its uncompressed form.

In this regard, it is contemplated that the computation 545 may impactonly the data of memory areas 512 and 514. This data may be fed to theprocessor 540 for computation and restored to the appropriate memoryareas by the decompression logic 550.

As previously noted, in addition to the actual data (e.g., actualcontents of memory 510) being compressed, the compression logic couldalternatively operate on addresses, such that the processor 540 would beconfigured to receive an identification of starting addresses of thememory areas 512 and 514. The processor 540 could then retrieve(directly from the memory 510) the relevant data, as appropriate, forperforming the computation 545.

With regard to the decompression logic 550, if the compression logic 525is structured similar to the logic illustrated in FIG. 9, then a similarreciprocal structure may be provided to perform the decompression. Sucha structure is illustrated in FIG. 14. A separate detailed discussion ofthis figure is not deemed to be necessary, as the description of thestructure and operation of FIG. 9 is sufficient to understand theoperation of the structure 600 provided in FIG. 14, being that thestructure performs a reciprocal operation. In this regard, thedecompression logic 600 includes a plurality of multiplexers arranged inrows 602, 604, 606, and 608 and columns CO through C15. Each multiplexerhas a control input (e.g., u0, 1 controls input selection of multiplexer0,1). By controlling the values of the plurality of multiplexer controlinputs, the decompression performed by the logic of FIG. 14 iscontrolled, in a manner similar to that of FIG. 9.

Having described the operation of various structural embodiments, itwill be appreciated that embodiments of the invention are directed tovarious methods for performing a variable length compression. Oneembodiment is directed to a method for a computer graphics systemcomprising compressing a plurality of groups of bits by shiftingcompressed groups of bits into bit positions that are to be removedduring the compression, the logic being responsive to a mask, whereincontents of the mask define variable amounts that the plurality of bitsare shifted during the compression. Another embodiment is directed to amethod for compressing a plurality of groups of bits to eliminate groupsof bits that are to be unaffected by a computation, performing thecomputation, and thereafter decompressing corresponding data afterperforming the computation to restore data corresponding to previouslyeliminated groups of bits.

It should be appreciated that there are a variety of novel featuresembodied in the embodiments of this application. These include thevariable-length compression of information within a component of agraphics pipeline, the architectural implementation of a packer using anarray of multiplexers, wherein the control input of each multiplexer isuniquely controlled; a method of using a bit or pixel mask forcontrolling compression levels in a packing function, etc.

The foregoing description is not intended to be exhaustive or to limitthe invention to the precise forms disclosed. Obvious modifications orvariations are possible in light of the above teachings. Further, theembodiment or embodiments discussed were chosen and described to providethe best illustration of the principles of the invention and itspractical application to thereby enable one of ordinary skill in the artto utilize the invention in various embodiments and with variousmodifications as are suited to the particular use contemplated. All suchmodifications and variations are within the scope of the invention asdetermined by the appended claims when interpreted in accordance withthe breadth to which they are fairly and legally entitled.

1. A method for compressing data in a graphics system comprising:providing a mask identifying bits within a plurality of bits that arenot to be impacted by a computation; and generating a compressed bitstream, wherein the bits that are not to be impacted by the computationare not included in the compressed bit stream.
 2. The method of claim 1,wherein the providing a mask comprises providing a pixel maskcorresponding to a tile of pixels to be displayed on a display.
 3. Themethod of claim 1, wherein further comprising obtaining depthinformation from a z-buffer and using the depth information forgenerating information containing within the provided mask.
 4. Themethod of claim 1, wherein the generating further comprises shiftingindividual bits by an amount equal to a number of bit positions,preceding the current bit position, that are unaffected by thecomputation.
 5. A method for compressing a plurality of bits comprising:directing data to be compressed to a matrix of multiplexers, wherein thematrix of multiplexers are in a plurality of rows with multiplexers in afirst row have inputs connected to signals defining bits to becompressed and multiplexers of successive rows have inputs connected tooutputs of the multiplexers of the preceding row, wherein eachsuccessive row of multiplexers comprises fewer multiplexers than theprevious row; and controlling data select input signals for theplurality of multiplexers such that individual bits of the plurality ofbits are shifted varying amounts, the shift amount being determined by amask.
 6. The method of claim 5, wherein the controlling comprisesshifting individual bits of the plurality of bits by varying amountsbased on the contents of the mask, wherein each additional shift valueeffectively causes a shifted bit to overwrite a bit that is to beunaffected by a subsequent computation.
 7. The method of claim 6,wherein the controlling is configured to operate control logic to shiftindividual bits by an amount equal to a number of bit positions,preceding the current bit position, that are to be unaffected by thecomputation.
 8. The method of claim 5, wherein the mask is a pixel maskcorresponding to a tile of pixels to be displayed on a display.
 9. Amethod for a computer graphics system comprising compressing a pluralityof groups of bits based on a pixel mask, wherein contents of the pixelmask are derived by a determination of corresponding groups of bits thatare to be unaffected by a computation, the contents of the pixel maskdefining variable amounts that the plurality of bits are shifted duringthe compression.
 10. The method of claim 9, wherein each position of thepixel mask defines a shift amount for a group of bits.
 11. The method ofclaim 10, wherein the content of each position of the pixel mask isdefined by a single bit, and the shift amount for a group of bits isdefined by a summation of preceding pixel mask positions whose contentsindicate corresponding pixels are not to be affected by a subsequentcomputation, wherein the positions of the pixel mask are arranged in anorder and the preceding pixel mask positions are those that, as ordered,numerically precede a given position.
 12. A method comprising:compressing a plurality of groups of bits to eliminate groups of bitsthat are to be unaffected by a computation; performing the computation;and decompressing corresponding data after performing the computation torestore data corresponding to previously eliminated groups of bits. 13.The method of claim 12, wherein computation is a pixel shadingoperation.
 14. A method for a graphics system comprising: providing amask identifying positions within a plurality of positions of a bitstream that are to be removed during a compression operation; andgenerating, based on the mask, a compressed bit stream, wherein thepositions that to be removed are removed by variably shifting contentsof successive positions by an appropriate amount so as to overwritecontents of positions that are to be removed.
 15. The method of claim14, wherein the mask is a pixel mask corresponding to a tile of pixelsto be displayed on a display.
 16. The method of claim 14, wherein thegenerating comprises shifting individual bits of the bitstream byvarying amounts based on the contents of the mask, wherein eachadditional shifted bits effectively overwrites bits that are to beunaffected by the computation.
 17. The method of claim 16, furthercomprising controlling the generating to shift individual bits by anamount equal to a number of bit positions, preceding the current bitposition, that are to be removed.
 18. A method for a computer graphicssystem comprising compressing a plurality of groups of bits by shiftingcompressed groups of bits into bit positions that are to be removedduring the compression, the logic being responsive to a mask, whereincontents of the mask define variable amounts that the plurality of bitsare shifted during the compression.